statement-store: add event-fed v2 peer topology#12217
Conversation
|
All GitHub workflows were cancelled due to failure one of the required jobs. |
|
Change the base to feature branch statement-store-dht |
| #[derive(Debug, Clone, Default)] | ||
| struct PeerInfo { | ||
| statement_protocol: ProtocolSupport, | ||
| dht_eligible: bool, |
There was a problem hiding this comment.
So I am honestly not sure we need this, assuming that ProtocolSupport::Supported is equivalent to dht_eligible = true.
I assume only sutuation when peer support "protocol" but not dht_eligible is when it is a light node. But they should not get in to this flow at all? If it is maybe we should just distinct by the node type {Full, Light}
| self.peer_store_handle.add_known_peer(peer_id.into()); | ||
| let peer = peer_id.into(); | ||
| self.peer_store_handle.add_known_peer(peer); | ||
| self.event_streams.send(Event::PeerDiscovered(peer)); |
There was a problem hiding this comment.
It seem that this even bus is very global and used by bunch of parachain subsystems, so I assume even when node is a RelayChain validator it will be receiving all this event although it should not
Summary
This PR adds the initial statement-store v2 peer topology wiring. #11933
It introduces backend-neutral network events for peer discovery and identify
metadata:
Event::PeerDiscovered(PeerId)Event::PeerIdentified { peer, supported_protocols }Both
libp2pandlitep2pbackends now emit these events from their existingdiscovery/routing-table and identify paths.
The statement handler consumes these events and updates a new
PeersTopologymodule. The topology keeps a local view of statement-capablepeers learned from network discovery, identify metadata, and statement
notification connections.
Design notes
PeersTopologyintentionally computes closest peers over the locally learnedpeer set. It does not perform topic-specific Kademlia lookups.
The topology currently supports: